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The NASA Dryden Flight Research Center flew two Hyper-X Research Vehicles and 
achieved hypersonic speeds over the Pacific Ocean in March and November 2004. To train 
the flight and mission control room crew, the NASA Dryden simulation capability was 
utilized to generate telemetry and radar data, which was used in nominal and emergency 
mission scenarios. During these control room training sessions, personnel were able to 
evaluate and refine data displays, flight cards, mission parameter allowable limits, and 
emergency procedure checklists. Practice in the mission control room ensured that all 
primary and backup Hyper-X staff were familiar with the nominal mission and knew how to 
respond to anomalous conditions quickly and successfully. This paper describes the 
technology in the simulation environment and the mission control center, the need for and 
benefit of control room training, and the rationale and results of specific scenarios unique to 
the Hyper-X research missions. 


Nomenclature 


AFB 

Air Force base 

AIP 

initial point 

ALCH 

launch point 

APWR 

power transfer point 

AREV 

reverse point 

BIT 

built- in-test 

CVT 

current-value table 

DECOM 

decommutator 

DFRC 

Dryden Flight Research Center 

EAFB 

Edwards Air Force Base 

EDW 

Edwards 

EP 

emergency procedure 

FADS 

flush air data system 

FMU 

flight management unit 

FTS 

flight termination system 

GMN 

Gorman 

GPS 

global positioning system 

GRIM 

Global Real-Time Interactive Map 

GVO 

Gaviota 

g 

gravitational unit 

HDOT 

altitude rate 

HXLV 

Hyper-X Launch Vehicle (modified Pegasus® rocket) 

HXRV 

Hyper-X Research Vehicle 

INALT 

inertial altitude 
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LaRC 

Langley Research Center 

LBITOR 

health summary bit 

MCC 

Mission Control Center 

NASA 

National Aeronautics and Space Administration 

NAWC-WD 

Naval Air Warfare Center Weapons Division 

NZF 

vertical acceleration, filtered 

NZUF 

vertical acceleration, unfiltered 

N z 

vertical acceleration 

PAGE 

Project Application Graphics Executable 

PCM 

pulse-coded modulation 

PDS 

Parameter Display System 

SIM3DApp 

an in-house software application 

TIE 

Test Information Engineer 

TRAPS 

Telemetry /Radar Acquisition Processing 

VME 

VERSAmodule Eurocard, a microcomputer bus 

WATR 

Western Aeronautical Test Range 

WINGS 

WATR Integrated Next Generation System 


I. Introduction 

T he Hyper-X program was an experimental flight research program intended to demonstrate advanced hypersonic 
technologies. 1 The primary research objective was to flight-test an airframe- integrated scramjet, which could 
pave the way for high-speed aircraft and the next generation of reusable launch vehicles. The NASA Langley 
Research Center (LaRC, Hampton, Virginia) was the Hyper-X program lead, and the NASA Dryden Flight Research 
Center (DFRC, Edwards, California) led the flight-test effort. Three Hyper-X Research Vehicles (HXRVs), 
collectively known as X-43A, were built for the Hyper-X program. All three vehicles were virtually identical; the 
main difference among them was the internal scramjet engine flowpaths. The first vehicle was intended to be flown 
to Mach 7 on June 2, 2001. It was destroyed along with its Pegasus® (Orbital Sciences Corporation, Dulles, 
Virginia) booster rocket approximately 48 s after launch because of a loss of control of the booster. 2 The second 
vehicle was successfully flown to Mach 6.8 on March 27, 2004, and effectively demonstrated the in-flight operation 
of its scramjet. All of the goals for that mission, including positive acceleration of the vehicle by the scramjet, were 
achieved. The third and final mission of the program was flown to Mach 9.7 on November 16, 2004, again 
successfully demonstrating positive engine acceleration. 

Control room training was an essential part of the preparation for all three Hyper-X missions. Previous work for 
flight 1 is described in Ref. 3. The state of the art for the 2001 first flight was further improved in the interim period 
before the 2004 flight 2 mission. This paper describes the control room training need, technological capability, and 
implementation philosophy for X-43 A flights 2 and 3 . 

II. Hyper-X Program Description and Training Need 

The HXRV was an unmanned vehicle that measured approximately 12 ft long and 5 ft wide, and weighed 
approximately 3,000 lb. A modified Pegasus® rocket booster known as the Hyper-X Launch Vehicle (HXLV), 
developed by Orbital Sciences Corporation of Chandler, Arizona, carried the X-43A to the test condition. The 
HXRV was mounted to the nose of the HXLV and the mated HXLV-HXRV stack was carried to the launch point 
under the wing of the NASA B-52 aircraft, tail number 008. After the B-52 aircraft took off from Edwards Air Force 
Base (EAFB), the stack was flown over the Pacific Ocean to approximately 40,000 ft and Mach 0.8 where it was 
released from the B-52 heading due west. A few seconds after drop, the HXLV rocket motor ignited, propelling the 
stack to a separation altitude of approximately 110,000 ft. After the HXRV separated from the HXLV, the engine 
cowl door on the HXRV opened, enabling engine ignition and operation for approximately 10 s. After engine 
shutdown, the cowl door was closed, and an unpowered descent trajectory was flown to a splashdown in the Pacific 
Ocean. This flight trajectory is depicted visually in Figure 1 . 
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The B-52, with the stack mated under its wing, took off from EAFB in the Western Aeronautical Test Range 
(WATR) of DFRC, with a transition to the Naval Air Warfare Center Weapons Division (NAWC-WD) Sea Range 
for the drop, boost, experiment, descent, and splashdown portions of the mission. The entire mission following the 
drop from the B-52 was carried out autonomously, and the HXRV was not recovered after splashdown. The 
expected flightpath over the NAWC-WD Sea Range was calculated so that any potential mission debris would land 
in designated weapons testing zones, which are free of boat traffic during NAWC-WD missions. 


In order to launch the vehicle in the calculated hazard zones, the stack had to be dropped from the B-52 precisely 
within a 3-minute launch window while the B-52 was flying at Mach 0.8. To meet this launch objective, waypoints 
along the B-52 ground track from EAFB were defined. Mission planners from the DFRC Operations Engineering 
branch carefully defined activities during the 45 -minute captive-carry flight to the launch point so that all in-flight 
vehicle preparations would take place on a timed schedule. These waypoints and the B-52 ground track are outlined 
in Fig. 2. The B-52 both originated and ended its flight at EAFB (noted by the EDW waypoint). Table 1 describes 
the activities onboard the B-52 along the B-52 flight profile. The entire research mission was controlled and 
monitored by the flight research team in the DFRC Mission Control Center (MCC). 
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Figure 2. B-52 ground track and waypoints prior to HXRV launch. 


Table 1. B-52 flight profile description and personnel responsibilities. 




Waypoint 

Mission 

time 

(hh:mm) 

Functions performed before next waypoint 

t# 

Label 

Description 



1 

EDW 

B-52 take-off from 
EAFB 

00:25 

B-52 pilot perfonns phasing maneuvers 

2 

GMN 

Landmark 

00:35 

Transition from WATR assets to NAWC-WD Range assets 

3 

GVO 

Last over- land point 

00:44 

HXLV FTS power on 

HXRV power on, built-in-test, and power off 

4 

APWR 

Power transfer point 

00:56 

HXLV FTS power transfer 
HXRV system checks 

5 

ALCH 

Launch point (in 
reverse) 

01:04 

Steady flight for HXLV engineers to monitor weather 
conditions in the launch box 
HXLV FTS tone checks 

6 

AREV 

Reverse point 

01:14 

HXRV system checks 

7 

AIP 

Initial point 

01:20 

(L-9) 

Final B-52 speed and altitude adjustments to achieve optimal 

HXLV launch condition 

HXRV system condition verification 

HXRV and HXLV transfer to internal power 

HXRV built-in test 

Safety hooks and pins removed 

HXLV fin actuation system power up and built-in test 

HXRV valves uninhibited 

HXRV Adapter cameras on 

8 

ALCH 

Launch point 

01:29 

B-52 pilot launches the HXLV on cue from DFRC MCC 
Monitor stations onboard B-52 powered down 

9 

GVO 

Over-land point 

01:42 

Release NAWC-WD assets and return to WATR assets 

10 

GMN 

Landmark (in reverse) 

01:51 


11 

EDW 

Landing at EAFB 

01:58 

Post-launch task list 
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As Table 1 illustrates, the majority of the systems checks and maneuvers occurred in the launch-minus-9-minute (L- 
9-minute) window between the initial point (AIP) and the launch point (ALCH). These actions included final B-52 
heading, altitude, and speed correction directives; research vehicle internal battery, pressurized fuel system, and 
flight computer navigation-mode enabling; and launch vehicle battery squib, fin-pin, and fin-sweep activation. 
Operators onboard the B-52 performed these tasks, based on direction from the DFRC mission controller. Located in 
the DFRC MCC, the DFRC mission controller received inputs from the HXRV and HXLV chief engineers, who 
were receiving information from the research engineers monitoring the telemetered downlink data. For all 
waypoints, and for the last L-9 minute period in particular, these actions had to be carefully executed in order and on 
time, so that the B-52 arrived on condition at the designed launch box. Preflight operations for an X-43A mission 
took approximately seven days to complete (with some personnel staffing 24-hour shifts), so there was a big 
incentive to safely and successfully launch on the first attempt, which required the near-perfect execution of tasks 
during the B-52 flight profile. For this reason, extensive control room training was conducted to ensure the operator, 
the controller, and the engineer familiarity with the execution of their tasks. 

During the B-52 flight to ALCH, control room engineers were expected to monitor vehicle health and status, 
reporting to the chief engineer that the systems were either on condition or that there was an anomaly. The project 
personnel defined a go/no-go list of parameters and values by which decisions to proceed to launch were made. 
Hyper-X Mission Control could not afford to launch this one-of-a-kind vehicle if any system was malfunctioning; 
conversely, each launch attempt cost approximately $500,000, so there was incentive not to return to EAFB 
unnecessarily. Control room training is essential to ensure that everyone has internalized their portion of the go/no- 
go parameter set. There were personnel changes between each of the X-43A flights, and nearly a three-year 
downtime between flight 1 and flight 2, so training was needed to keep everyone proficient at their role. In addition, 
each station had a primary and a backup person, so control room training was required to ensure that both potential 
participants were comfortable in their role. 

Emergency procedure (EP) checklists were on -hand in case project engineers noticed any of the possible flight 
hazards during the prelaunch phase of the B-52 flight profile. Some of the high risks during the B-52 flight included 
potential leaks in the HXRV fuel system, a fire in either the onboard HXRV silane system or the HXLV, and high 
wing loading on the B-52. Responses to these types of emergencies ranged from venting the HXRV fuel system or 
jettisoning the entire stack, to slowing the B-52 to reduce wing loading. As in the case of the go/no-go parameter set, 
execution of the emergency procedures had to be well-thought-out but initiated quickly, because of the risk to the 
flight crew, population centers on the ground, and mission hardware. Control room training is essential to ensuring 
crew familiarity with hazard conditions and the execution of emergency procedure response checklists. 

Training was also performed in a captive-carry mission, in which the B-52 flies the expected profile with the HXRV 
and HXLV in a mated but not live condition. A captive-carry mission was performed prior to each of the three 
X-43A missions. This is, however, costly due to the WATR and NAWC-WD range assets [telemetry, radar, voice 
communications, flight termination system (FTS), and video systems] which must be scheduled to support the flight. 
Captive-carry missions are also high-risk, because flight hardware is being exposed to potential damage, and the B- 
52 is being stressed by carrying the weight of the stack. It is not practical to perform multiple captive-carry missions. 
For this reason, a simulated training environment was required to prepare X-43A operators, controllers, and 
engineers for the successful execution of mission tasks. 

Using the X-43A simulation equipment, it was possible to generate a pulse-coded modulation (PCM) telemetry 
stream that exactly simulated the downlink telemetry stream, and send it to the MCC for display to end users. In this 
manner, the entire B-52 flight could be practiced, with simulated parameter values, so that participants could learn 
what to expect during a nominal flightpath. The simulated PCM stream also allowed for the injection of parameter 
failures, so that the X-43A team could practice executing emergency procedures. For control room training 
exercises, an extra person was used in the MCC. This training conductor was tuned in to the voice communications 
links between the mission controller and the B-52 operators, so that he could hear when commands had been issued 
or steps had been executed. The training conductor would then relay that command to the simulation engineer, so 
that the appropriate activity could be simulated in the parameter values in the PCM stream. 
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III. Simulation Environment 

The NASA Dryden Flight Research Center Research Aircraft Integration Facility (RAIF) and its simulation 
capabilities support the most advanced flight research projects through all phases of vehicle design, development, 
systems integration, verification, validation, and flight-test. A total of nine simulation labs offer data and 
communication interfaces to the aircraft test bays to accomplish combined systems testing. Data and communication 
interfaces are also provided to the Dryden MCC supporting combined system testing, control room training, and 
mission planning. 

The NASA Dryden HXRV simulation was primarily developed to support verification and validation (V&V) of the 
Hyper-X avionics. The FiXRV simulation is a complex six-degree-of-freedom (6-DOF) simulation including models 
for aerodynamics, engine, control system, and actuators. Modifications were made to the simulation to support 
control room training by flying a predefined B-52 flight profile. 

When the simulation is used for control room training, the following physical equipment is utilized (see Fig. 3). 



060168 


Figure 3. HXRV simulation data flow for control room training purposes. 

For the Hyper-X missions, three PCM downlink streams were simulated (HXRV, HXLV, and B-52). To 
simulate these streams of data, a VERSAmodule Eurocard (VME) chassis containing three PCM simulator/encoder 
cards was added to the simulation configuration. 

Data from the simulation is transferred to the VME chassis through a replicated shared-memory interface. This 
interface provides for the sharing of information between different operating systems and hardware platforms. The 
simulated PCM data consists of approximately 700 parameters (out of a total of approximately 2100 for the three 
Hyper-X PCM streams). Parameters not actively modeled in the simulation were simply assigned nominal values 
which they retained unless perturbed by an emergency procedure scenario. A problem to be faced in simulating 
PCM data is the requirement to convert the desired engineering unit output to counts. For linear calibrations, an 
inverse calibration can be directly obtained. For higher order calibrations, the Newton-Raphson method is used to 
numerically invert the polynomial. This technique is described in Ref. 4. 

In addition to the PCM downlink data, the position of the B-52 is tracked by the WATR radar. To simulate this 
data stream, the simulation used one of the serial outputs of the simulation computer to send simulated radar data to 
the MCC. The radar data consists of the simulation of a single radar site within the WATR. This data is computed in 
the simulation from the latitude, longitude, and altitude of the aircraft. This data is transmitted out of the simulation 
via a serial (RS-232) data line, with an output rate of 20 Hz to match radar processing rates. 

The flight profile of the B-52 was simulated by predefined latitude, longitude, and altitude values for the aircraft 
position as a function of time. This pennitted simulations from aircraft takeoff, to the launch point, and to a landing 
back at EAFB. In addition, the simulation could be started at any point in this flight profile - for example, to focus 
on a particular phase of the mission. 
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The use of scenario-based simulation scripts provided the flexibility necessary to introduce simulated failures 
and events at arbitrary times. For example, a scenario script was used to accomplish the vehicle pass/no pass built- 
in-test (BIT) of the HXRV’s flight management unit (FMU) for flight-surface actuation, in response to a call for that 
operation from the mission controller. All of the scenario-based scripts contain predefined sequences of operations 
(usually the assigning of vehicle parameter data for output via the PCM data streams). The scripts include built-in 
delays to simulate real world events. Each scenario was coded into a single script with a corresponding reset script. 
Close coordination with the training conductor via the voice network was required to properly execute scripts at 
critical times. 


IV. Mission Control Center Environment 

The MCCs are an asset in the WATR at DFRC. Dedicated lines from WATR telemetry and radar equipment 
provide input to the Telemetry/Radar Acquisition Processing System (TRAPS) facility, which processes data for 
transmission to the MCCs, where it can be displayed to project engineers. In the case of a control room simulation 
mission, the TRAPS input is switched to use PCM and serial radar data from the HXRV simulation environment via 
dedicated fiber lines from the RAIF. Hyper-X missions for vehicles 2 and 3 utilized the TRAPS in the WATR 
Integrated Next Generation System (WINGS) 1.8 configuration. Further detail on the WINGS phased development 
approach can be found in Ref. 5. A block diagram of the data flow between the aircraft, TRAPS, and MCC is shown 
in Fig. 4. 



Figure 4. Data flow between data source, TRAPS, and MCC. 

The WINGS 1.8 system utilizes a Wyle Laboratories (El Segundo, California) Omega telemetry front end. 
Calculations on telemetry parameters to create new derived parameters are performed using two in-house software 
applications (one running at rate on every data sample, and a second legacy program running on a subsample of the 
data set). Derived calculation code was incorporated in the HXRV simulation so that the desired control room 
training values of the derived calculations could be produced in the simulation environment. 

Within the WINGS 1.8 system, all PCM and radar data is recorded on magnetic analog tape drives. It is also 
recorded in digital archive format so that it can be converted into time-history data and stored for long-term retrieval 
on DFRC internal flight data servers. 

The MCCs in the WINGS 1.8 system offer a suite of in-house software programs for displaying flight data. The 
parameter display system (PDS) is a quickly reconfigurable software application that displays parameter values from 
a current-value table (CVT). Common data display types in PDS include numeric readouts of parameter values, 
color light boxes indicating parameter state, message words based on discrete parameter values, bar graphs, and time 
history displays. A second CVT-based application, PAGE (Project Application Graphics Executable) is utilized 
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when enhanced graphic display capabilities are required. For the X-43A project, PAGE displays included 
visualization of fluids states and levels, and three-dimensional sketches of the FIXRV with contour shading to 
represent temperature and pressure conditions at different locations on the vehicle. If parameters are required at rate 
(not sampled through a CVT), they are displayed on a physical strip-chart in the WINGS 1.8 MCC configuration. 
The two MCCs utilized for X-43A missions contained a total of eighteen eight-channel strip-charts at engineer 
workstations. For Hyper-X missions, a total of 51 PDS displays and sixteen PAGE control room displays were 
maintained by the WATR and viewed by project personnel during missions. 

In addition to the display of telemetry and derived parameters, the WINGS 1.8 configuration provides a Global 
Real-time Interactive Map (GRIM). The GRIM utilizes radar and aircraft data to display an aircraft’s location on a 
world map. Within the GRIM, custom restricted areas can be predefined on the world map. For the X-43A project, 
all of the waypoints were entered in the GRIM so that the mission controller could monitor success in passing each 
waypoint on condition as well as estimate arrival time at the next waypoint. In addition, the X-43A launch box and 
hazard debris areas over the Pacific Ocean were displayed. Range safety personnel utilize the GRIM to predict areas 
of impact in the event of FTS activation. 

The X-43A missions also employed a dedicated in-house application called the Sim3DApp. This program 
received a broadcast of HXRV parameters from a server application running on the TRAPS front end. The 
Sim3DApp uses aircraft data to display a three-dimensional visual image of the B-52, HXLV, and HXRV in flight. 
Due to the high speed and altitude of the HXRV experiment, optical tracking was only available for the beginning of 
the rocket boost phase. The Sim3DApp was the only visualization of the separation, experiment, and descent 
parameter identification maneuvers (PID) available for the X-43A program. 

The MCCs at DFRC are equipped with over 20 stations running either PDS, PAGE, or GRIM. Overhead video 
monitors are provided, and communications panels are available at every workstation to provide voice networks 
between research engineers, the mission controller, the chief engineers, pilots and operators onboard aircraft, the 
simulation engineer (in a training situation), and WATR operations personnel. 

V. Control Room Training Sessions 

Everyone who had a role in the B-52 flight and HXLV-HXRV stack launch participated in X-43A control room 
Raining exercises: the mission controller, the HXRV and HXLV chief engineers, the discipline engineers, the range 
control officer (RCO), the range safety officer (RSO), the test information engineer (TIE), the WATR equipment 
operators, the B-52 pilot, the B-52 onboard launch panel operator (LPO), and the B-52 onboard HXRV station 
operator (RV). Discipline engineers in the MCC included aerodynamics, flight systems, propulsion, instrumentation, 
guidance, navigation and control, and structures personnel for the HXRV, as well as HXLV development and 
integration engineers. 

Additionally, two other people were necessary for the control room training exercises: the simulation engineer 
and the training conductor. A dedicated voice network between the training conductor and the simulation engineer 
was established to coordinate the execution of training scenarios. No one else in the room could hear this voice 
communication, so there was an element of surprise if an emergency situation was introduced by the training 
conductor. 

Prior to flight 1, two EP training sessions were conducted using the technology described in Ref. 3. The Hyper-X 
solution detailed in Ref. 3 was put together in a limited timeframe of only a few months, with a very limited budget. 
The simulation capability at the time did not generate a PCM stream; rather, a computer in the TRAPS generated 
and broadcast over Ethernet directly to the PDS and PAGE displays. The GRIM and strip-charts in the control room 
could not be used because there was no simulated radar stream and no telemetry counts were received in the front 
end for conversion and display on strip-charts. No data recordings or postflight data could be generated from this 
method of control room training. In the nearly three-year downtime between flights 1 and 2, the DFRC simulation 
engineering branch was able to procure PCM simulator cards and develop the capability to send a simulated PCM 
stream to the TRAPS directly from the HXRV simulation environment. The capabilities described herein mark an 
improvement upon the capability for flight 1 : engineers are now able to view simulated strip-charts and GRIM data, 
and simulated sessions can be recorded for postflight analysis. In addition, the simulated PCM stream allows for the 
operation of the Sim3DApp for flight visualization. As a side benefit, a more complete set of the operational 
equipment is utilized by this new method so it can be verified and personnel can gain experience. 
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Prior to flight 2, a total of seven control room training sessions were held using the HXRV simulation. Between 
flight 2 and flight 3, an additional six control room training sessions were held. Each session lasted between two and 
four hours. Each session began with a nominal takeoff scenario for the B-52. After the simulated takeoff, however, 
the makeup of the training session was markedly different, depending on whether the training had been designated 
as nominal or an EP session. Prior to each EP training session, the training conductor and mission controller 
identified training goals and specific team training topics. The actual content and timing of the emergency scripts 
that were eventually developed for each EP training session, however, were known only to the training conductor 
and the simulation engineer. The X-43 mission controller was in training himself, and was not forewarned of 
simulation events, as everyone else on the team. 

Within each EP training session, a progression of emergency scripts was run concurrent with the preprogrammed 
nominal simulation. The script would typically change specific parameters and eventually time out with one 
parameter or more in excess of their allowable go/no-go values. The EP scenarios were designed around, among 
other things, failed pressure sensors, a failed accelerometer, leaking valves, a hot telemetry transmitter, oxygen 
incursion within the HXRV, a fire within the HXRV, short-circuited battery systems, failed actuator linkages, and a 
structurally failed pylon hook. 

The discipline engineers responsible for monitoring specific parameters would react to the simulated emergency 
with a call to their respective lead engineer. If the lead engineer concurred, he or she would report the situation and 
the suggested EP to the mission controller for formal execution of the steps. The EPs resulted in either the 
continuation of the flight, an abort of the drop and a recycle attempt, or a mission abort and a retum-to-base call to 
the B-52. After meeting this final condition, the simulation would be paused for discussion of the scenario. 
Typically, a single EP scenario, from the start of the script to the pause of the simulation, could last as long as 10 to 
20 minutes. It was not uncommon, particularly if the EP script had exposed some procedure deficiency or confusion 
in communication protocol, for the discussion to last as long as the EP scenario itself. 

VI. Experience With Control Room Training Scenarios 

To make the best use of the control room training time, the team held roundtable discussions to learn and refine 
the mission EPs. The scenarios were designed by the training conductor to test the team’s knowledge of the EPs and 
go/no go lists. An example of a typical control room EP scenario as developed by the training conductor is shown in 
Table 2. Table 2 represents the way in which the scenario was documented to the simulation engineer, who took this 
information and generated a script for the simulation environment. This particular scenario involves a subtle, and 
quite unlikely, failure of a solid-state accelerometer within the FMU. This was designed specifically to train the 
controllers to maintain vigilance on the less obvious failure parameters. The layout of Table 2 shows the general 
timing used during a typical script. It also illustrates that different parameters were altered during the script to 
simulate some real-world change as a result of the specific failure being simulated. 
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Table 2. Emergency procedure scenario example. 


Name Elapsed Increment Parameter Off- Nominal Parameter Comment Discipline 

time, s delta time, ID nominal value name observing 

s Value 


EP 

0 

0 

NZF 

-0.5 

1.0 g 

FMU normal C Systems, 

#M3 






acceleration 

Aerodynamics, 

(Nz 

0 

0 

NZUF 

-0.5 

1.0 g 

Unfiltered 

Controls, 

failure) 






normal 

Mission 







acceleration 

Controller 


0 

0 

HDOT 

-2000 

0.0 fps 

Vertical 








velocity 



0 

0 

INALT 

40000 

40,000 

Inertial 







ft 

altitude 



2.5 

2.5 

INALT 

37500 





5 

2.5 

INALT 

35000 


« This is a mission rule 







violation 


7.5 

2.5 

INALT 

32500 





10 

2.5 

INALT 

30000 





12.5 

2.5 

INALT 

27500 





15 

2.5 

INALT 

25000 





17.5 

2.5 

INALT 

22500 







LBITOR: 

1 

0 

Master FMU health status BIT 



BIT 1709 


1 

0 

FMU HDOT numeric value error 



BIT 0602 


1 

0 

FMU accelerometer oscillator monitor failure 



BIT 0601 


1 

0 

FMU accelerometer temperature sensor 







failure 




BIT 0600 


1 

0 

FMU accelerometer digitizer saturation 







failure 



20 

2.5 

?t 

20000 





22.5 

2.5 

?t 

17500 





25 

2.5 

?t 

15000 





27.5 

2.5 

?t 

12500 





30 

2.5 

M 

10000 





32.5 

2.5 

M 

7500 





35 

2.5 

M 

5000 





37.5 

2.5 

INALT 

1000 





42.5 

5 

End script with NZF, NZUF, HDOT, and INALT parameters holding last shown 


off-nominal values 


In addition to standard parameter failures, another level of EP scenario was introduced that simulated a failure 
that did not technically violate the go/no-go procedures. For example, in the case of multiple and closely related 
sensors, the failure of one out of the set was permissible. In one scenario, instead of simulating an oxygen (02) 
incursion within the HXRV with a number of different 02 sensors showing over-limit 02 percentages, only a single 
02 sensor was shown to go over the mission limit, and its value immediately jumped to the maximum value. While 
the initial urge might be to declare an emergency due to oxygen incursion, the correct response was actually that the 
vehicle had a single bad sensor and as such the go/no-go rules were not violated. Similar scenarios were designed 
around a single defective fire sensor and a single defective temperature sensor. 

Another form of EP scenario focused on exploring subtle aspects of the official EPs. One major safety concern 
was the health of the pylon holding the X-43A stack onto the B-52. If there was an unsafe condition over land, the 
procedures called for a mission abort and jettison of the pylon (with the X-43A stack still attached) in a remote 
desert area. In the scenario concerning this mission rule, the B-52 onboard HXRV station operator was told to report 
that he had indication of “two pylon lights on.” These lights are not monitored on ground displays, and indicated a 
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serious problem within the pylon. This emergency was simulated at the L-5-minute point, during an extremely busy 
time onboard the B-52 and in the MCC. The immediate reaction in the MCC was to abort the drop and begin 
preparation for the B-52 to jettison the stack. However, since the call was made while the flight was over the Sea 
Range, the correct procedure for this case was to continue with the nominal drop mission and to jettison the pylon 
sometime after the drop. When this same scenario was repeated at a later session the mission controller correctly 
acknowledged the issue, and proceeded with the nominal predrop procedures. 

One EP scenario resulted in a considerable amount of postscenario discussion. It involved a script that had the S- 
band telemetry transmitter temperature increase significantly, but never exceed the maximum allowed limit of 1 80 
degrees F. Then it cooled down and randomly fluctuated to represent a noisy signal, right around the parameter’s 
go/no-go value of 140 degrees F. This scenario was run at about the L-8-minute point and resulted in the responsible 
engineer aborting the flight. The key, however, was that the script terminated with the transmitter’s temperature 
static at 139 degrees F, an allowable temperature according to the mission go/no-go rules. Although no one could 
dispute the engineer’s decision, the scenario created considerable discussion about the “what-if s” of this situation. 
Many thought it more hazardous to the mission to be needlessly overcautious and return to EAFB for a later attempt, 
rather than continue the flight with a tolerable (according to the mission rules) instrument problem. Although this 
particular scenario does not have a straightforward solution, it benefited the team by exposing personnel to a 
possible scenario, creating an opportunity for them to evaluate their response to this situation. 

As mentioned earlier, the L-9-minute period was the most critical for executing the HXRV launch, so all training 
sessions typically included repeated L-9-minute runs to get the entire team not only complying with the required 
pace but actually improving the clarity of their communication and getting comfortable with the critical procedural 
timing. Of course, these L-9-minute runs also provided a prime opportunity for the training conductor to implement 
EP scenarios to enhance the stress on the team, and to challenge their compliance with communications protocols 
during this communications-heavy period. One particularly challenging EP scenario, initiated by the training 
conductor at L-3 minutes, presented an intentional decrease in instrument battery voltage combined with an increase 
in S-band transmitter temperature. Neither of these scenarios was intended to cause initiation of an EP; rather, they 
served as a distraction for the already busy flight systems team. The actual emergency situation was the intermittent 
change in a critical status word that relates to the activation of the valves onboard the HXRV. This situation 
occurred at L-20 seconds and required a mission abort call from the lead flight systems engineer, which was 
correctly handled in the training session. Scenarios such as this helped the personnel stay focused and perceptive, 
and to communicate with clarity in the face of a highly stressful situation such as they might face on the actual day 
of the flight. 

Other EP scenarios were specially designed to simulate unusual failures within the MCC infrastructure. These 
non-software-driven failures forced the team, and particularly the lead discipline engineers and the mission 
controller, to experience the situation live and later discuss the best methods to resolve the situation. For example, 
the intermittent loss of the telemetry link from the B-52 or X-43A was simulated with a technician literally pulling 
and reinserting the main PCM data input cable that was used to ultimately drive the displays in the control room. In 
one scenario, the electronics box controlling audio communications to a lead engineer was totally disabled. In 
another case, a lead engineer’s key graphic display was shut down. To accentuate the stress, and simulate a worst- 
case event, each of these latter two events were performed with no forewarning and were timed to occur just prior to 
that key individual’s team experiencing an EP scenario that was specifically focused on their discipline. 

An interesting training phenomenon was noticed by the training conductor near the end of the training for flight 
2. When the final training session was announced as a nominal session it was noted that several members of the 
mission control team seemed to be complacent - they didn’t bring their EP books to the mission control center. 
Clearly there was zero expectation of any emergency events during the nominal training. Could this expectation 
affect training, and ultimately team performance? 

The answer to this question was yes, as quickly demonstrated by an improvised test near the end of that session. 
The training conductor unexpectedly inserted an emergency script that simulated a no-go increase in S-band 
transmitter temperature just prior to the “nominal” launch. Neither the responsible engineer monitoring that display 
nor the chief engineer also overseeing the same data, reported the anomaly, and instead allowed the mission 
controller to proceed with the launch. During post-session discussions they both stated that they did indeed see the 
no-go data but regarded it as a computer simulation anomaly because “this was a nominal training.” 
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The training received during the nominal and emergency training sessions was excellent. But this “nominal” 
conduct during a session with “nominal” expectations, in the face of data to the contrary, seemed somewhat counter- 
productive to the goal of training. As a result, it was recommended and implemented that all future sessions be 
announced as simply mission training sessions. Except for the mission controller, who aided the training conductor 
with the determination and prioritization of training issues and goals for each session, the team wouldn’t know if the 
training session was an EP or a nominal session. The result of this slight change to the training was clearly 
demonstrated just prior to flight 3 during a full nonstop 90-minute (and therefore assumed nominal) training session. 
At L-l minute (with no foreknowledge to anyone in the MCC) a go/no-go battery issue was simulated and the flight 
systems lead engineer immediately called the emergency and an abort, and the entire team responded with the 
appropriate emergency procedural call-outs. It was an excellent rehearsal and demonstrated that the team was ready 
for flight. 


VII. Control Room Training Benefit 

The Hyper-X project personnel reaped numerous benefits from the extensive control room training sessions that 
were conducted prior to flights 2 and 3. Due to the infrequent flights and months of downtime between missions, 
control room training was essential to providing the project personnel with recent experience and familiarity with 
the control center. Everyone participating became more familiar with the pace of operations and the time allotted for 
each step in the flight cards. Inexperienced personnel used training to get accustomed to the monotony of monitoring 
virtually static displays for over an hour as the B-52 flew offshore to the drop point. Development of crew discipline 
and focus was noticeable as multiple training sessions were conducted. Unlike the major portion of the B-52’s flight, 
the final nine minutes immediately preceding the drop event were communication- and action-intense. This L-9- 
minute portion of the flight was rehearsed repeatedly in both the nominal and the EP training sessions. In some 
cases, the practice revealed areas where a reassessment of the timing or execution of steps was required, and the 
flight cards were fine-tuned. Revisions of the flight cards were produced between each of the early control room 
training sessions as lessons learned from the exercise were incorporated into the cards. 

In addition to fine-tuning the flight cards, project personnel were able to refine the go/no-go list and the EP 
checklists based on the control room training sessions. When the training conductor triggered a retum-to-base call 
based on specific parameter temperature or pressure limits from the go/no-go list, in many cases a lengthy 
discussion on the true hard limit for that parameter would occur, and the project was able to perfect the allowable 
ranges of mission parameter values. It would be unacceptable for a debate on a mission parameter limit to take place 
during an actual mission; repeated testing of the limits in a training session allowed for preflight debate and 
discussion on appropriate mission parameter limits. Also, in one training session, a pressure over-limit call to vent 
the onboard systems was initiated by someone outside the propulsion group based on a review and misinterpretation 
of the data values displayed. This prompted a discussion by the group, and as a result, the Hyper-X team redefined 
the allowable initiators of EPs based on this experience in the training environment. Crew members also identified a 
need to speak succinctly and present information to the mission controller in a standard order every time, so an 
abbreviated language about EPs was bom out of the practice in the control room training sessions. Repeated 
emergency scenarios in the final L-9-minute commotion helped the personnel practice staying focused, perceptive, 
and clearheaded in the face of highly stressful situations. 

The control room training exercises utilizing the simulation also allowed for verification of the calibration 
information contained in the Calibration Information Management System (CIMS) file. When the simulation was 
used to reverse-engineer a counts value for a desired engineering unit (EU) value, the displayed value in the WATR 
could be used to test if the calibration information was valid and functional. 

While the flight and control room crews benefited from the training sessions, WATR personnel involved were 
also receiving valuable practice and testing opportunities. Range operations personnel became familiar with the 
setup and execution of Hyper-X missions, because without these simulated sessions, there would have been few 
opportunities to practice configuring the control room for end users. The TIE was able to test all 67 control room 
displays, the derived calculation code, and strip-charts with the simulated PCM stream. Engineers could see their 
displays “in action” rather than in a static testing mode, and that triggered many modifications to the way data was 
calculated and displayed to the end user. In the early development of the capability, the ability to record sessions and 
generate postsession time-history data files proved valuable to the training conductor, TIE, and simulation engineer 
for testing and verifying the control room training scenarios. Finally, using a simulated PCM stream was the only 
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means of verifying the Sim3DApp used for visualization of stack ascent, separation event, HXRV experiment, and 
HXRV descent into the ocean. 


VIII. Conclusion 

The capability to simulate multiple telemetry streams and radar data in order to train flight and mission control 
personnel for a flight project at the NASA Dryden Flight Research Center has been successfully demonstrated. This 
technology was used to simulate in-flight emergency scenarios for the Hyper-X program and provide a means for 
the crew to practice several mission profiles. 

These training sessions: 

• Improved crew response and communications 

• Verified and improved control room displays 

• Verified calibration coefficients 

• Verified operational equipment 

• Improved checklists and go/no-go limits 

• Resulted in a safer mission. 

Crew training via simulated in-flight scenarios in the Dryden Mission Control Centers was an essential part of 
the preparation for Hyper-X research missions. Control room training was a cost-effective means of ensuring both 
flight safety and mission success for the Hyper-X air launches. As both the crew and the simulation training team 
gained familiarity with the capabilities of the system, the fidelity of the training sessions was improved and project 
personnel were able to perfect their data displays, go/no-go launch conditions, emergency procedures, and the flight 
cards. The control room training environment served as a nonthreatening place for personnel to learn their roles and 
practice responding efficiently to highly stressful simulated emergency scenarios. According to Dryden Hyper-X 
chief engineer Griffin Corpening, “this hard work and training paid off (in the form of) three flawless captive-carry 
flights and three flawless launch operations.” 
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